IMS (IP Multimedia Subsystem) is a set of standards providing the signalling, delivery, authentication and billing functions necessary for real-time, packet-based calls and services across virtually any underlying network technology. In other words, IMS is a platform adapted for an efficient and rapid implementation of next-generation IP services in both fixed and mobile networks which will accelerate the convergence of fixed and wireless networks.
The Session Initiation Protocol (SIP) is a transport independent, text based-application-layer control protocol for creating, modifying and terminating sessions involving one or more participants, including internet calls, multimedia distributions and multimedia conferences. SIP is widely used as a signalling protocol for voice over IP, and has been accepted as a 3rd Generation Partnership Project (3GPP) signalling protocol for the IMS.
In the 3GPP IMS Domain Name System (DNS), domains are used to identify to what SIP domain a user belongs. In previously known applications, one DNS domain can only be represented by one SIP domain, which may be e.g. an IMS domain. Such a restriction may become a problem, for example for a multinational enterprise having outsourced their communication solution by investing e.g. in an IMS based IP-centrex/telephony Virtual Private Network (VPN) technology. Typically for this type of scenario, the users are spread over the world, wherein users of different geographical regions normally are managed by different operators, each managing different IMS domains.
A simplified method for handling an incoming request for an IMS related service at an IMS domain “domain1.com” 100, managed by operator A, according to the prior art will now be described with reference to FIG. 1. It is to be understood that, although management of an IMS domain normally involves more nodes and signalling than what is shown in FIG. 1, nodes and signalling steps which are not necessary for the understanding of the general procedure for handling an incoming request have been omitted, for simplicity reasons.
In a first stage 1:1, a request addressed to “user1”, having a URI, such as e.g. “user1@domain1.com” reaches an Interrogating Call Session Control Function (I-CSCF) 101 of operator A, i.e. the operator responsible for managing the IMS domain, “domain1.com”. In order to be able to route the request to “user1”, the DNS domain name of the request has to be properly resolved. This may be achieved by interrogating a user database of operator A, typically a Home Subscriber Server (HSS) 102, in a next stage 1:2. The HSS is the main data storage for all IMS-related subscriber- and service data of the IMS domain of operator A. The main data stored in the HSS includes a user profile for each user, registered to the IMS domain. The user profile comprises user information for routing an incoming request to an Serving CSCF (S-CSCF), and further to the terminating user entity. A user profile is a collection of user-specific information that is permanently stored in the HSS, including public user identities, which may be a SIP URI, e.g., bob.home@domain1.com, or a tel URIs, e.g., tel:+46 8 123 456 67.
If the interrogation of the HSS 102 results in a match, the request is routed to the relevant S-CSCF 103, of operator A, as indicated with a stage 1:3a. From S-CSCF 103 the request is forwarded towards the intended terminating entity, such as e.g. an Application Server (AS) (not shown), which may provide the requested service to the requesting party. If, however, no match is found at the HSS query, the request is rejected, resulting in a failure for operator A to provide the requested service to the requesting party. This alternative is indicated with an alternative final stage 1:3b. 
A company like Ericsson, having a URI scheme with URIs like e.g. “user1@ericsson.com”, may want to be able to use the “ericsson.com” domain internationally, rather than only regionally. No solution for providing such a feature is, however, known today.